The following abbreviations are herewith defined, at least some of which are referred to within the following description of the prior art and the present invention.                ARP Address Resolution Protocol        CFM Connectivity Fault Management        DLL Data Link Layer        DSCP Differentiated Services Code Point        IEEE Institute of Electrical and Electronic Engineers        IETF Internet Engineering Task Force        IP Internet Protocol (versions 4 or 6)        IS-IS Intermediate System to Intermediate System (routing protocol)        L1L2 Layer 1, Layer 2 (boundary)        L2 Layer 2        L3 Layer 3        LAN Local Area Network        LBM Loop Back Message        LLDP Link Layer Discovery Protocol        LLDP-MED LLDP—Media Endpoint Discovery        MTU Maximum Transmission Unit        OSI Open Systems Interconnect        PDU Protocol Data Unit        TLV Type Length Value        TRILL Transparent Routing over Lots of Links        VLAN Virtual Local Area Network        
The discussion herein relates to Ethernet networking and in particular to shortest path bridging using IS-IS link-state routing or any other Data-Link Layer technology where devices need to be aware of the actual or real MTU size. Two proposals currently exist for performing shortest path bridging: (1) the ongoing work in the Internet Engineering Task Force (IETF) Transparent Routing over Lots of Links (TRILL) working group; and (2) the ongoing work in the IEEE 802.1 Interworking working group that works with IEEE 802.1Qaq-d1-5 entitled “Virtual Bridged Local Area Networks—Amendment 9: Shortest Path Bridging” (the contents of which are incorporated by reference herein).
The TRILL and IEEE proposals each use IS-IS routing which is natively designed for a variety of Network Layer (L3) transmission and forwarding technologies (commonly referred to as L3 routing), including IP, an OSI address based routing. In such L3 technologies, there is no problem if routing peers fail to discover links that do not support the same MTU size as is defined for each routing peer. However, in L2 technologies the use of IS-IS for shortest path determination and forwarding is an example where it is critical that the routing peers know the real MTU size for a network path. In particular, in L2 technologies which use shortest path bridging with IS-IS link-state routing, it is critical that the IS-IS peers know the real MTU size so they can discover each other as otherwise it will be possible to establish persistent loops in the layer 2 forwarding topology.
This problem can occur when two adjacent IS-IS peers do not discover each other using the IS-IS hello protocol because the discovery PDUs are too large and as such each peer will decide that they are the designated forwarder for the local link. Thus, each peer will be unable to distinguish PDUs forwarded by the other peers from the PDUs sent by other end-stations in the network, and those peers will blindly forward them. In this situation, the network ends-up with invisible re-forwarders, causing the PDUs to be repeatedly forwarded by each peer. This is actually the likely outcome, given the way that IS-IS (and several other similar protocols) tend to stuff (often by padding) the PDUs and in particular the discovery PDUs.
To prevent the creation of L2 persistent loops, an IS-IS peer shortest path bridging instance needs to know a priori what the real MTU size is for its connection to an adjacent IS-IS shortest path bridge. This will prevent the over-stuffing of the PDUs to a size in excess of the real MTU size for the path connecting key end-stations. Thus, where broadcast/multicast PDUs are used in broadcast-based L2 technologies, the MTU used would need to be determined as the least MTU size for all paths. However, in certain applications where an L2 participating device is an Ethernet (or other DLL) end-station, it is useful to know the MTU between the two end-stations independent of the MTU values that may apply in links not included in the L2 forwarding path between those two end-stations. This allows for unicast PDUs to be forwarded at the largest real MTU size for the path connecting the two end-stations.
Thus, while it is possible to simply configure an MTU for an entire L2 network that is equal to the least MTU of any link in the network, this approach may result in a lower value of MTU than is actually required for most end-station pairs. Although there are approaches that can be used in IP networks to determine the real MTU between pairs of end-stations these approaches cannot be applied to L2 networks since there is not an error reporting mechanism in L2 networks that includes the capability to report to a sender that a PCU was dropped as “big.” Accordingly, there is a need to address this problem by enabling end-station pairs to determine the real MTU for their DLL connection. This need and other needs have been satisfied by the present invention.